Today's communication networks are large, and the number of resources and services provided is increasing. Network equipment often comes from different vendors, and network operators use a variety of different operations and management systems to manage their networks. Each vendor's equipment often has its own management system, and different services in the network are controlled in different ways. All of these factors increase the complexity and cost for operations and maintenance.
One way to simplify that complexity and reduce the cost for network operators is to develop an international standard on how telecommunications networks will be managed in a uniform and efficient way. For example, the Third Generation Partnership Project (3GPP) is developing standards for the third generation (3G) of mobile communications systems. The standard documents 3GPP TS 32.101-102 describe various 3G management principles and architectures. Example management functions addressed in the 3GPP specifications include fault management, configuration management, performance management, roaming management, accounting, customer profile management, service deployment, fraud management, security management, and software management. The ITU Technical Specification Recommendation M.3100 is another management standard for telecom networks.
Notwithstanding these efforts at standardization, a mobile network operator may still have to manage many different types of networks, such as radio networks, exchanges, transmission networks, area networks, intelligent nodes, and substantial amounts of computer hardware/software. Because this wide variety of network equipment will likely be obtained from a variety of equipment vendors, effective configuration management is particularly critical in order to flexibly manage and adapt the topology and logical resources in the network.
Configuration management employs a Network Resource Model (NRM) to represent the actual managed telecommunication network resources. An NRM describes managed object classes, their associations, attributes, and operations. A Managed Object (MO) is a software object that encapsulates management characteristics and behavior of a particular network resource. The managed object is an “instance” of a “managed object class” defined in an NRM A managed object class has attributes that provide information used to characterize the objects that belong to the class. In addition, a managed object class can have operations that represent the behavior relevant for that class. An instance of a managed object class is sometimes called a “managed element.” Associations are used to model relationships between managed objects and can be implemented in several ways, such as name bindings, reference attributes, and association objects. A management information base (MIB) is an instance of an NRM and includes a name space describing the managed object hierarchy in the MIB using distinguished names, a number of managed objects with their attributes, and a number of associations between these managed objects.
Part of the configuration management function in the network management system is to identify and eliminate inconsistencies in a network. A network may be represented in a valid configuration or in a planned network configuration. Typically, these configurations are “checked” for consistency using a large number of consistency check rules. Those rules represent best practices or desired practices regarding network configurations. For example, if a radio base station is to be added to a network, consistency check rules might ensure that the new base station is configured with a unique identifier, appropriate radio channels, and particular transmit power levels. The consistency check rules are usually quite voluminous, and all of them must be performed on every object in the configuration being checked. Consequently, when an operator initiates a consistency check after a system installation or a system restart, that check may take considerable time.
Indeed, hundreds of consistency check rules may have been developed and must be performed on all managed objects and their attributes in the configuration being checked. Such rules might check for the uniqueness of an identifier of a particular node, for a particular frequency range, for a maximum number of frequencies, for a maximum number of a particular type of channel, for maximum power levels, etc. Consider the example situation in a cellular network where a new cell D is going to be added to an existing configuration that already has cells A, B, and C with corresponding cell IDs. A consistency check is executed to ensure that the cell ID for cell D is not the same as any of the cell IDs already assigned to cells A, B, and C.
Consistency checks help the network operator avoid faulty attribute settings in a particular network configuration. Faulty settings would include, for example, attribute values that nodes within a network will not accept or values that would degrade the system characteristics and functionality within a node or between nodes. Because consistency checks of attribute settings is primarily performed before attributes are set in the network, most consistency checks are executed in a planned configuration, referred to hereafter as a “planned area.” However, since inconsistencies may be present in actually configured networks, consistency checks can also be performed on a live network, referred to hereafter as a “valid area.”
A network operator is usually provided with a very long list of pre-coded, consistency check rules. Again, it is not uncommon for a network operator to have to select from a list of hundreds of such pre-coded rules when a particular consistency check is to be performed on a planned area or active area configuration. Although all of the consistency check rules may be selected, it may be that the network operator only wants to use some of those rules rather than all of them. This is especially true given the amount of time it takes to execute a large number of such rules. Alternatively, operators may want to create their own consistency check rules other than or in addition to those on the pre-coded list. In this case, the network operator must go back to the management system vendor who supplied the original management system software with the pre-coded consistency check rules and ask the vendor to code new consistency check rules. Of course, time and money are required to develop such software upgrades.
It is therefore desirable for network operators to have the flexibility to create consistency check rules without having to re-code the management software or request a software upgrade from a network management software vendor. It is also desirable to provide the network operator with some choice as to when a consistency check rule is executed. As an example, when “populating” a planned area, the integrity of the populating data could be high because it was created automatically. This means that consistency checking of this populating data could be done only when a change of the data is made directly in the valid area. The integrity of other populating data (e.g., manually created) could be lower, and thus, the consistency check should be done either at population of the planned area or when upgrading the valid area. The network vendor has little or no knowledge about the integrity of the populating data before it populates the planned area, which is why the decision of when to perform consistency checking lies best with the operator of the network. Pre-coded consistency check rules do not provide operators with this option.
The present invention overcomes these shortcomings by providing a flexible consistency checking mechanism that allows network operators to generate their own consistency checking rules using a consistency check rule making/editing functionality. In a preferred example embodiment, several basic consistency check formulas are provided. Each formula defines one (or more) general operations performed on one or more managed network objects. By applying the general consistency check formulas to one or more specific managed network objects, one or more consistency check rules is created. The user can create the consistency check rules simply by inputting certain data values for formula variables by way of a user interface or file transfer. Once those rules have been created, they can be used to check the consistency of one or more aspects of a communications network configuration, either in a planned area or a valid area. Because the formulas are general, a single formula can be used to generate multiple consistency check rules using different managed objects and attributes.
Another advantageous aspect of the present invention is that each consistency check formula may include a “checkpoint” which defines a time period or an event when a corresponding consistency check rule established using that formula should be executed. In other words, when an operator uses one of the formulas to define a new consistency check rule, the operator also connects or otherwise associates that new consistency check rule to a particular checkpoint or event when rule execution is to occur. Examples of possible checkpoints in a cellular network context include immediate creation of a cell, activation of a cell, creation of a location area, import of new data to the network management system from an external management system, i.e., the planned area check, and an initial start of a network element or a management system. Of course, many other events may be defined as checkpoints.
As a result of the operator-defined consistency check functionality provided by the present invention, an operator will have the ability to create, delete, and change consistency check rules for a network without requiring a software upgrade or even assistance from a network management software vendor. Only those consistency check rules actually desired by the operator for a particular network area need be created. Moreover, the network operator will also be able to determine a time (and modify that time if desired) when a consistency check rule will be executed without requiring a software upgrade. This leads to shorter times in upgrading the operator's network with less time being spent doing consistency checking during population and validation of the planned area. The integrity of the data nonetheless remains high with consistency checking being performed when necessary.